REMARKS 



INTERVIEW SUMMARY 

Applicants appreciate the courtesy extended by the Examiner in conducting telephone 
interviews with the undersigned on May 1 1 and 12, 201 1 . Conclusions of the interviews are 
included in the following remarks. 

INDEPENDENT CLAIM 24 

Claim 24 is rejected as obvious over Shiimori in view of Adler. This rejection should be 
withdrawn for the following reasons: 

Claim 24, as amended, recites a server "storing ... a font capabilities list for each of multiple 
client devices, each font capabilities list comprising a list of fonts for which the respective individual 
device has font structure data, the font structure data defining the structure in which text formatted 
with the respective font is to be rendered." After transferring new font structure data to the device, 
the server "update[s] the font capabilities list of the designated device by adding, to the font 
capabilities list, the font whose font structure data was transferred to the designated device." 

These two limitations, of 1) a server storing a font capabilities list for each individual device, 
and 2) the server updating the list by adding the font whose structure data was transferred to the 
device, are not disclosed by the references even in combination. 

The Advisory Action asserts this is suggested by Adler' s disclosure of: 

"Step 40 includes consulting a database associated with intermediate network device to 
determine what glyph sub-sets already exist on the electronic device. In such an 
embodiment, the electronic device may be identified by a device type identifier included 
in a header associated with a request. Only those glyphs that do not already exist on the 
electronic device are obtained at Step 40." (Adler, col. 12, lines 28-35, emphasis added) 

However, as this block quote from Adler states, Adler's database does not store the font 
capabilities of any individual device as claimed. It instead stores the font capabilities of a "device 
type", where "type" designates between computer, cell phone, PDA, etc. (Adler, col. 4, lines 47- 
51). Nor can Adler's database be, as claimed, "updated" to reflect new font structure data being 
sent to the individual device, since Adler's database is not associated with the individual device but 
instead with that general device "type". 
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Shiimori, too, does not suggest either of these two limitations. This is understood based on 
the following explanation of what Shiimori discloses. Shiimori discloses a server that assists a client 
computer in editing an image. The server provides different user-selectable editing "services" 
depending on the image to be edited. The "services" include a service to edit a postcard, a service to 
edit a business card, and a service to edit a postcard image. As clarified in Shiimori (col. 2, lines 
1-22 and Figs. 4 and 10), each image-editing session starts with the client computer sending (Step 44 
in Fig. 4; Step 91 in Fig. 10) to the server an indication of what service (whether to edit a postcard, 
or a business card, etc.) it wants and a list of fonts it (the computer) can output. The server then 
compares this capabilities list of fonts received from the computer to a capabilities list of fonts that 
the server itself can handle, to yield a subset list of fonts that are common to both capabilities lists. 
This subset list is thus a list of "fonts capable of being output at both the client computer and the 
server." (Shiimori, col. 2, lines 8-9) The server then sends this subset list to the computer. The 
computer then edits the image using only the fonts that are in the subset list. This ensures that any 
image edited by the computer can be output by both the computer and the server. 

Accordingly, Shiimori's server never sends font structure data to a device as claimed, but 
only a list of fonts. In fact, Shiimori's procedure is designed to ensure that all image-editing is done 
with the fonts the client device already has. Nor does Shiimori's server "store" a font capabilities 
list for each individual device of multiple devices as claimed; it has no reason to, since it receives a 
new font capabilities list from the client computer at the start of each image-editing session. Nor is 
Shiimori's server capable of, as claimed, "updating" a font capabilities list to reflect the new font 
structure received by the device receives, since Shiimori's client device never receives any new font 
structure data. 

The Advisory Action asserts that the claim step of the server updating the font capabilities 
list ~ defined as the list of fonts for which the device has structure data — corresponds to Shiimori's 
disclosure (col. 8, lines 16-57 and Figs. 13-14) of adding fonts to a font list. However, the font list 
being updated in Shiimori is not the claimed the list of fonts for which the device has structure data, 
but is instead the aforementioned list of fonts that the server itself is capable of. (Shiimori, col. 7, 
lines 59-62) And the updating of the font list in Shiimori is not done by the server in response to a 
client device receiving new font structure as claimed, but instead by an operator using the server's 
"display unit" to manually "register" a new font to be used by the server itself. 

Since both references, even in combination, lack both limitations mentioned above, the 
rejection over these two references should be withdrawn. 
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INDEPENDENT CLAIM 40 

Claim 40, like claim 24, is rejected over Shiimori in view of Adler. This rejection should be 
withdrawn for the following reasons: 

Claim 40, as amended, recites a server "storing ... a font capabilities list for each of multiple 
client devices, each font capabilities list comprising a list of fonts for which the respective individual 
device has font structure data, the font structure data defining the structure in which text formatted 
with the respective font is to be rendered." 

As explained above regarding claim 24, this limitation of a server storing a font capabilities 
list for each individual device is not disclosed by the references even in combination. 

Therefore, the rejection of claim 24 should be withdrawn. 

NEW INDEPENDENT CLAIM 43 

Claim 43 is similar to claim 24. But claim 24 omits the limitations, from claim 24, of the 
designated device storing the received font structure data and the server updating the client profile. 

Claim 43 includes limitations, absent from claim 24, of the server "determining that another 
font identifier, that is not on the font capabilities list of the designated device and not one of the font 
identifiers in the text data, corresponds to a same type of font as one of the font identifiers in the text 
data" and "transferring, to the designated device, font structure data of said another font identifier." 

This is supported in the specification at p. 13, line 16 to p. 14, line 6, in which a server 
transfers, to the designated device along with text data, structure data for font fsm that is not 
identified in the text data, but is nevertheless a same type of font as font fd2 that is identified in the 
text data. 

In the aforementioned telephone interview, the Examiner agreed that these method steps are 
not disclosed by the cited references. 

DEPENDENT CLAIMS 26-30, 41-42 and 44 

The remaining claims are dependent claims. They are distinguished further from the prior art 
by the limitations they add to the independent claims. 
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The application is therefore now in condition for allowance. 



Respectfully submitted, 

Mitchell Rose, (Reg. No. 47,906) 
JONES DAY 
901 Lakeside Ave. 
Cleveland, OH 44114 
(216)586-7094 



